Architektura frontendu: Architektura heksagonalna i czysta architektura dla skalowalnych aplikacji

W miarę wzrostu złożoności aplikacji frontendowych, dobrze zdefiniowana architektura staje się kluczowa dla utrzymania, testowalności i skalowalności. Dwa popularne wzorce architektoniczne, które odpowiadają na te potrzeby, to architektura heksagonalna (znana również jako porty i adaptery) oraz czysta architektura. Chociaż wywodzą się one ze świata backendu, ich zasady można skutecznie zastosować w tworzeniu frontendu, aby tworzyć solidne i elastyczne interfejsy użytkownika.

Czym jest architektura frontendu?

Architektura frontendu definiuje strukturę, organizację i interakcje różnych komponentów w aplikacji frontendowej. Stanowi ona plan, według którego aplikacja jest budowana, utrzymywana i skalowana. Dobra architektura frontendu promuje:

• Łatwość utrzymania: Łatwiejsze zrozumienie, modyfikacja i debugowanie kodu.
• Testowalność: Ułatwia pisanie testów jednostkowych i integracyjnych.
• Skalowalność: Pozwala aplikacji radzić sobie z rosnącą złożonością i obciążeniem użytkowników.
• Wielokrotne użycie: Promuje ponowne wykorzystanie kodu w różnych częściach aplikacji.
• Elastyczność: Dostosowuje się do zmieniających się wymagań i nowych technologii.

Bez jasnej architektury projekty frontendowe mogą szybko stać się monolityczne i trudne w zarządzaniu, co prowadzi do zwiększonych kosztów rozwoju i zmniejszonej zwinności.

Wprowadzenie do architektury heksagonalnej

Architektura heksagonalna, zaproponowana przez Alistaira Cockburna, ma na celu oddzielenie kluczowej logiki biznesowej aplikacji od zewnętrznych zależności, takich jak bazy danych, frameworki UI i interfejsy API firm trzecich. Osiąga to poprzez koncepcję portów i adapterów.

Kluczowe koncepcje architektury heksagonalnej:

• Rdzeń (Domena): Zawiera logikę biznesową i przypadki użycia aplikacji. Jest niezależny od wszelkich zewnętrznych frameworków czy technologii.
• Porty: Interfejsy definiujące, w jaki sposób rdzeń komunikuje się ze światem zewnętrznym. Reprezentują one granice wejścia i wyjścia rdzenia.
• Adaptery: Implementacje portów, które łączą rdzeń z konkretnymi systemami zewnętrznymi. Istnieją dwa typy adapterów:
• Adaptery sterujące (pierwotne): Inicjują interakcje z rdzeniem. Przykłady obejmują komponenty UI, interfejsy wiersza poleceń lub inne aplikacje.
• Adaptery sterowane (wtórne): Są wywoływane przez rdzeń w celu interakcji z systemami zewnętrznymi. Przykłady obejmują bazy danych, interfejsy API lub systemy plików.

Rdzeń nie wie nic o konkretnych adapterach. Komunikuje się z nimi wyłącznie za pośrednictwem portów. To oddzielenie pozwala na łatwą wymianę różnych adapterów bez wpływu na logikę rdzenia. Na przykład można przełączyć się z jednego frameworka UI (np. React) na inny (np. Vue.js), po prostu zastępując adapter sterujący.

Zalety architektury heksagonalnej:

• Lepsza testowalność: Kluczowa logika biznesowa może być łatwo testowana w izolacji, bez polegania na zewnętrznych zależnościach. Można użyć atrap adapterów (mock adapters) do symulacji zachowania systemów zewnętrznych.
• Większa łatwość utrzymania: Zmiany w systemach zewnętrznych mają minimalny wpływ na logikę rdzenia. Ułatwia to utrzymanie i rozwijanie aplikacji w czasie.
• Większa elastyczność: Można łatwo dostosować aplikację do nowych technologii i wymagań, dodając lub zastępując adaptery.
• Lepsza możliwość ponownego użycia: Kluczowa logika biznesowa może być ponownie wykorzystana w różnych kontekstach poprzez podłączenie jej do różnych adapterów.

Wprowadzenie do czystej architektury

Czysta architektura, spopularyzowana przez Roberta C. Martina (Wujka Boba), to kolejny wzorzec architektoniczny, który kładzie nacisk na separację odpowiedzialności (separation of concerns) i oddzielenie. Skupia się na tworzeniu systemu, który jest niezależny od frameworków, baz danych, interfejsu użytkownika i wszelkich czynników zewnętrznych.

Kluczowe koncepcje czystej architektury:

Czysta architektura organizuje aplikację w koncentryczne warstwy, gdzie najbardziej abstrakcyjny i uniwersalny kod znajduje się w centrum, a najbardziej konkretny i specyficzny technologicznie kod na zewnętrznych warstwach.

• Encje (Entities): Reprezentują kluczowe obiekty biznesowe i reguły aplikacji. Są niezależne od wszelkich systemów zewnętrznych.
• Przypadki użycia (Use Cases): Definiują logikę biznesową aplikacji i sposób, w jaki użytkownicy wchodzą w interakcję z systemem. Orkiestrują one encje w celu wykonania określonych zadań.
• Adaptery interfejsów (Interface Adapters): Konwertują dane między przypadkami użycia a systemami zewnętrznymi. Ta warstwa obejmuje prezentery, kontrolery i bramy (gateways).
• Frameworki i sterowniki (Frameworks and Drivers): Najbardziej zewnętrzna warstwa, zawierająca framework UI, bazę danych i inne technologie zewnętrzne.

Zasada zależności w czystej architekturze mówi, że warstwy zewnętrzne mogą zależeć od warstw wewnętrznych, ale warstwy wewnętrzne nie mogą zależeć od warstw zewnętrznych. Zapewnia to, że kluczowa logika biznesowa jest niezależna od jakichkolwiek zewnętrznych frameworków czy technologii.

Zalety czystej architektury:

• Niezależność od frameworków: Architektura nie opiera się na istnieniu jakiejś biblioteki oprogramowania bogatej w funkcje. Pozwala to na używanie frameworków jako narzędzi, zamiast być zmuszonym do umieszczania systemu w ich ograniczonych ramach.
• Testowalność: Reguły biznesowe można testować bez interfejsu użytkownika, bazy danych, serwera WWW ani żadnego innego elementu zewnętrznego.
• Niezależność od UI: Interfejs użytkownika można łatwo zmienić, nie zmieniając reszty systemu. Interfejs WWW można zastąpić interfejsem konsolowym, nie zmieniając żadnych reguł biznesowych.
• Niezależność od bazy danych: Możesz zamienić Oracle lub SQL Server na Mongo, BigTable, CouchDB lub coś innego. Twoje reguły biznesowe nie są powiązane z bazą danych.
• Niezależność od jakiegokolwiek czynnika zewnętrznego: W rzeczywistości Twoje reguły biznesowe po prostu nie wiedzą *nic* o świecie zewnętrznym.

Zastosowanie architektury heksagonalnej i czystej architektury w tworzeniu frontendu

Chociaż architektura heksagonalna i czysta architektura są często kojarzone z tworzeniem backendu, ich zasady można skutecznie zastosować w aplikacjach frontendowych w celu poprawy ich architektury i łatwości utrzymania. Oto jak:

1. Zidentyfikuj rdzeń (domenę)

Pierwszym krokiem jest zidentyfikowanie kluczowej logiki biznesowej Twojej aplikacji frontendowej. Obejmuje to encje, przypadki użycia i reguły biznesowe, które są niezależne od frameworka UI czy jakichkolwiek zewnętrznych API. Na przykład w aplikacji e-commerce rdzeń może obejmować logikę zarządzania produktami, koszykami na zakupy i zamówieniami.

Przykład: W aplikacji do zarządzania zadaniami, rdzeń domeny mógłby składać się z:

• Encje: Zadanie (Task), Projekt (Project), Użytkownik (User)
• Przypadki użycia: UtwórzZadanie, ZaktualizujZadanie, PrzypiszZadanie, UkończZadanie, WyświetlZadania
• Reguły biznesowe: Zadanie musi mieć tytuł, zadanie nie może być przypisane do użytkownika, który nie jest członkiem projektu.

2. Zdefiniuj porty i adaptery (architektura heksagonalna) lub warstwy (czysta architektura)

Następnie zdefiniuj porty i adaptery (architektura heksagonalna) lub warstwy (czysta architektura), które oddzielają rdzeń od systemów zewnętrznych. W aplikacji frontendowej mogą to być:

• Komponenty UI (Adaptery sterujące / Frameworki i sterowniki): Komponenty React, Vue.js, Angular, które wchodzą w interakcję z użytkownikiem.
• Klienci API (Adaptery sterowane / Adaptery interfejsów): Usługi, które wykonują żądania do backendowych API.
• Magazyny danych (Adaptery sterowane / Adaptery interfejsów): Local storage, IndexedDB lub inne mechanizmy przechowywania danych.
• Zarządzanie stanem (Adaptery interfejsów): Redux, Vuex lub inne biblioteki do zarządzania stanem.

Przykład z użyciem architektury heksagonalnej:

• Rdzeń: Logika zarządzania zadaniami (encje, przypadki użycia, reguły biznesowe).
• Porty: TaskService (definiuje metody tworzenia, aktualizacji i pobierania zadań).
• Adapter sterujący: Komponenty React, które używają TaskService do interakcji z rdzeniem.
• Adapter sterowany: Klient API, który implementuje TaskService i wykonuje żądania do backendowego API.

Przykład z użyciem czystej architektury:

• Encje: Zadanie (Task), Projekt (Project), Użytkownik (User) (czyste obiekty JavaScript).
• Przypadki użycia: CreateTaskUseCase, UpdateTaskUseCase (orkiestrują encje).
• Adaptery interfejsów:
  • Kontrolery: Obsługują dane wejściowe od użytkownika z UI.
  • Prezentery: Formatują dane do wyświetlenia w UI.
  • Bramy (Gateways): Wchodzą w interakcję z klientem API.
• Frameworki i sterowniki: Komponenty React, klient API (axios, fetch).

3. Zaimplementuj adaptery (architektura heksagonalna) lub warstwy (czysta architektura)

Teraz zaimplementuj adaptery lub warstwy, które łączą rdzeń z systemami zewnętrznymi. Upewnij się, że adaptery lub warstwy są niezależne od rdzenia i że rdzeń komunikuje się z nimi wyłącznie za pośrednictwem portów lub interfejsów. Pozwala to na łatwą wymianę różnych adapterów lub warstw bez wpływu na logikę rdzenia.

Przykład (architektura heksagonalna):

// Port TaskService
interface TaskService {
  createTask(taskData: TaskData): Promise;
  updateTask(taskId: string, taskData: TaskData): Promise;
  getTask(taskId: string): Promise;
}

// Adapter klienta API
class ApiTaskService implements TaskService {
  async createTask(taskData: TaskData): Promise {
    // Wykonaj żądanie API w celu utworzenia zadania
  }

  async updateTask(taskId: string, taskData: TaskData): Promise {
    // Wykonaj żądanie API w celu aktualizacji zadania
  }

  async getTask(taskId: string): Promise {
    // Wykonaj żądanie API w celu pobrania zadania
  }
}

// Adapter komponentu React
function TaskList() {
  const taskService: TaskService = new ApiTaskService();

  const handleCreateTask = async (taskData: TaskData) => {
    await taskService.createTask(taskData);
    // Zaktualizuj listę zadań
  };

  // ...
}

Przykład (czysta architektura):

// Encje
class Task {
  constructor(public id: string, public title: string, public description: string) {}
}

// Przypadek użycia
class CreateTaskUseCase {
  constructor(private taskGateway: TaskGateway) {}

  async execute(title: string, description: string): Promise {
    const task = new Task(generateId(), title, description);
    await this.taskGateway.create(task);
    return task;
  }
}

// Adaptery interfejsów - Brama (Gateway)
interface TaskGateway {
  create(task: Task): Promise;
}

class ApiTaskGateway implements TaskGateway {
  async create(task: Task): Promise {
    // Wykonaj żądanie API w celu utworzenia zadania
  }
}

// Adaptery interfejsów - Kontroler
class TaskController {
  constructor(private createTaskUseCase: CreateTaskUseCase) {}

  async createTask(req: Request, res: Response) {
    const { title, description } = req.body;
    const task = await this.createTaskUseCase.execute(title, description);
    res.json(task);
  }
}

// Frameworki i sterowniki - Komponent React
function TaskForm() {
  const [title, setTitle] = useState('');
  const [description, setDescription] = useState('');
  const apiTaskGateway = new ApiTaskGateway();
  const createTaskUseCase = new CreateTaskUseCase(apiTaskGateway);
  const taskController = new TaskController(createTaskUseCase);

  const handleSubmit = async (e: React.FormEvent) => {
    e.preventDefault();
    await taskController.createTask({ body: { title, description } } as Request, { json: (data: any) => console.log(data) } as Response);
  };

  return (
    

       setTitle(e.target.value)} />
       setDescription(e.target.value)} />
      <button type="submit">Utwórz zadanie</button>
    </form>
  );
}

</code>
</pre>

<h3>4. Zastosuj wstrzykiwanie zależności (Dependency Injection)</h3>

<p>Aby jeszcze bardziej oddzielić rdzeń od systemów zewnętrznych, użyj wstrzykiwania zależności, aby dostarczyć adaptery lub warstwy do rdzenia. Pozwala to na łatwą wymianę różnych implementacji adapterów lub warstw bez modyfikowania kodu rdzenia.</p>

<p><b>Przykład:</b></p>

<pre>
<code>
// Wstrzyknij TaskService do komponentu TaskList
function TaskList(props: { taskService: TaskService }) {
  const { taskService } = props;

  const handleCreateTask = async (taskData: TaskData) => {
    await taskService.createTask(taskData);
    // Zaktualizuj listę zadań
  };

  // ...
}

// Użycie
const apiTaskService = new ApiTaskService();
<TaskList taskService={apiTaskService} />
</code>
</pre>

<h3>5. Napisz testy jednostkowe</h3>

<p>Jedną z kluczowych zalet architektury heksagonalnej i czystej architektury jest lepsza testowalność. Możesz łatwo pisać testy jednostkowe dla kluczowej logiki biznesowej, nie polegając na zewnętrznych zależnościach. Użyj atrap adapterów lub warstw (mock adapters/layers) do symulacji zachowania systemów zewnętrznych i weryfikacji, czy logika rdzenia działa zgodnie z oczekiwaniami.</p>

<p><b>Przykład:</b></p>

<pre>
<code>
// Atrapa TaskService
class MockTaskService implements TaskService {
  async createTask(taskData: TaskData): Promise<Task> {
    return Promise.resolve({ id: '1', ...taskData });
  }

  async updateTask(taskId: string, taskData: TaskData): Promise<Task> {
    return Promise.resolve({ id: taskId, ...taskData });
  }

  async getTask(taskId: string): Promise<Task> {
    return Promise.resolve({ id: taskId, title: 'Test Task', description: 'Test Description' });
  }
}

// Test jednostkowy
describe('TaskList', () => {
  it('should create a task', async () => {
    const mockTaskService = new MockTaskService();
    const taskList = new TaskList({ taskService: mockTaskService });

    const taskData = { title: 'New Task', description: 'New Description' };
    const newTask = await taskList.handleCreateTask(taskData);

    expect(newTask.title).toBe('New Task');
    expect(newTask.description).toBe('New Description');
  });
});
</code>
</pre>

<h2>Praktyczne uwagi i wyzwania</h2>

<p>Chociaż architektura heksagonalna i czysta architektura oferują znaczne korzyści, istnieją również pewne praktyczne uwagi i wyzwania, o których należy pamiętać, stosując je w tworzeniu frontendu:</p>

<ul>
 <li><b>Zwiększona złożoność:</b> Te architektury mogą zwiększyć złożoność bazy kodu, zwłaszcza w przypadku małych lub prostych aplikacji.</li>
 <li><b>Krzywa uczenia się:</b> Deweloperzy mogą potrzebować nauczyć się nowych koncepcji i wzorców, aby skutecznie wdrożyć te architektury.</li>
 <li><b>Nadmierna inżynieria (Over-engineering):</b> Ważne jest, aby unikać nadmiernego komplikowania aplikacji. Zacznij od prostej architektury i stopniowo dodawaj złożoność w miarę potrzeb.</li>
 <li><b>Równoważenie abstrakcji:</b> Znalezienie odpowiedniego poziomu abstrakcji może być wyzwaniem. Zbyt duża abstrakcja może utrudnić zrozumienie kodu, podczas gdy zbyt mała może prowadzić do silnego powiązania.</li>
 <li><b>Kwestie wydajności:</b> Nadmierne warstwy abstrakcji mogą potencjalnie wpłynąć na wydajność. Ważne jest profilowanie aplikacji i identyfikowanie wszelkich wąskich gardeł wydajnościowych.</li>
</ul>

<h2>Międzynarodowe przykłady i adaptacje</h2>

<p>Zasady architektury heksagonalnej i czystej architektury mają zastosowanie w tworzeniu frontendu niezależnie od lokalizacji geograficznej czy kontekstu kulturowego. Jednak konkretne implementacje i adaptacje mogą się różnić w zależności od wymagań projektu i preferencji zespołu deweloperskiego.</p>

<p><b>Przykład 1: Globalna platforma e-commerce</b></p>

<p>Globalna platforma e-commerce może używać architektury heksagonalnej do oddzielenia kluczowej logiki zarządzania koszykiem i zamówieniami od frameworka UI i bramek płatniczych. Rdzeń byłby odpowiedzialny za zarządzanie produktami, obliczanie cen i przetwarzanie zamówień. Adaptery sterujące obejmowałyby komponenty React dla katalogu produktów, koszyka i stron kasy. Adaptery sterowane obejmowałyby klientów API dla różnych bramek płatniczych (np. Stripe, PayPal, Alipay) i dostawców usług wysyłkowych (np. FedEx, DHL, UPS). Pozwala to platformie łatwo dostosować się do różnych regionalnych metod płatności i opcji wysyłki.</p>

<p><b>Przykład 2: Wielojęzyczna aplikacja mediów społecznościowych</b></p>

<p>Wielojęzyczna aplikacja mediów społecznościowych mogłaby używać czystej architektury do oddzielenia kluczowej logiki uwierzytelniania użytkowników i zarządzania treścią od frameworków UI i lokalizacji. Encje reprezentowałyby użytkowników, posty i komentarze. Przypadki użycia definiowałyby, jak użytkownicy tworzą, udostępniają i wchodzą w interakcję z treścią. Adaptery interfejsów obsługiwałyby tłumaczenie treści na różne języki i formatowanie danych dla różnych komponentów UI. Pozwala to aplikacji na łatwe wspieranie nowych języków i dostosowywanie się do różnych preferencji kulturowych.</p>

<h2>Podsumowanie</h2>

<p>Architektura heksagonalna i czysta architektura dostarczają cennych zasad do budowy łatwych w utrzymaniu, testowalnych i skalowalnych aplikacji frontendowych. Poprzez oddzielenie kluczowej logiki biznesowej od zewnętrznych zależności, można stworzyć bardziej elastyczną i adaptowalną bazę kodu, którą łatwiej rozwijać w czasie. Chociaż te architektury mogą wprowadzać pewną początkową złożoność, długoterminowe korzyści w zakresie łatwości utrzymania, testowalności i skalowalności sprawiają, że są one wartą rozważenia inwestycją w przypadku złożonych projektów frontendowych. Pamiętaj, aby zacząć od prostej architektury i stopniowo dodawać złożoność w miarę potrzeb, a także starannie rozważyć związane z tym praktyczne aspekty i wyzwania.</p>

<p>Przyjmując te wzorce architektoniczne, deweloperzy frontendowi mogą budować bardziej solidne i niezawodne aplikacje, które mogą sprostać zmieniającym się potrzebom użytkowników na całym świecie.</p>

<h3>Dalsza lektura</h3>

<ul>
  <li>Architektura heksagonalna: <a href="https://alistaircockburn.com/hexagonal-architecture/">https://alistaircockburn.com/hexagonal-architecture/</a></li>
  <li>Czysta architektura: <a href="https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html">https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html</a></li>
</ul>
</div><footer class="mt-12 pt-8 border-t border-gray-200"><h3 class="text-sm font-semibold text-gray-900 mb-3 dark:text-white/90">Tags:</h3><div class="flex flex-wrap gap-2"><span class="inline-block bg-gray-100 text-gray-800 px-3 py-1 rounded-full text-sm hover:bg-gray-200 transition-colors dark:bg-neutral-800 dark:text-white dark:hover:bg-neutral-700">architektura frontendu</span><span class="inline-block bg-gray-100 text-gray-800 px-3 py-1 rounded-full text-sm hover:bg-gray-200 transition-colors dark:bg-neutral-800 dark:text-white dark:hover:bg-neutral-700">architektura heksagonalna</span><span class="inline-block bg-gray-100 text-gray-800 px-3 py-1 rounded-full text-sm hover:bg-gray-200 transition-colors dark:bg-neutral-800 dark:text-white dark:hover:bg-neutral-700">czysta architektura</span><span class="inline-block bg-gray-100 text-gray-800 px-3 py-1 rounded-full text-sm hover:bg-gray-200 transition-colors dark:bg-neutral-800 dark:text-white dark:hover:bg-neutral-700">rozwój frontendu</span><span class="inline-block bg-gray-100 text-gray-800 px-3 py-1 rounded-full text-sm hover:bg-gray-200 transition-colors dark:bg-neutral-800 dark:text-white dark:hover:bg-neutral-700">architektura oprogramowania</span><span class="inline-block bg-gray-100 text-gray-800 px-3 py-1 rounded-full text-sm hover:bg-gray-200 transition-colors dark:bg-neutral-800 dark:text-white dark:hover:bg-neutral-700">skalowalne aplikacje</span><span class="inline-block bg-gray-100 text-gray-800 px-3 py-1 rounded-full text-sm hover:bg-gray-200 transition-colors dark:bg-neutral-800 dark:text-white dark:hover:bg-neutral-700">testowalny kod</span><span class="inline-block bg-gray-100 text-gray-800 px-3 py-1 rounded-full text-sm hover:bg-gray-200 transition-colors dark:bg-neutral-800 dark:text-white dark:hover:bg-neutral-700">kod łatwy w utrzymaniu</span><span class="inline-block bg-gray-100 text-gray-800 px-3 py-1 rounded-full text-sm hover:bg-gray-200 transition-colors dark:bg-neutral-800 dark:text-white dark:hover:bg-neutral-700">architektura UI</span><span class="inline-block bg-gray-100 text-gray-800 px-3 py-1 rounded-full text-sm hover:bg-gray-200 transition-colors dark:bg-neutral-800 dark:text-white dark:hover:bg-neutral-700">architektura JavaScript</span><span class="inline-block bg-gray-100 text-gray-800 px-3 py-1 rounded-full text-sm hover:bg-gray-200 transition-colors dark:bg-neutral-800 dark:text-white dark:hover:bg-neutral-700">architektura TypeScript</span></div></footer></article></div><script>$RS=function(a,b){a=document.getElementById(a);b=document.getElementById(b);for(a.parentNode.removeChild(a);a.firstChild;)b.parentNode.insertBefore(a.firstChild,b);b.parentNode.removeChild(b)};$RS("S:2","P:2")</script><script>$RC("B:1","S:1")</script></body></html>